
            <!DOCTYPE html>
            <html lang="en">
            <head>
                <meta charset="UTF-8">
                <title>喜马拉雅容器化实践</title>
            </head>
            <body>
            <a href="https://andyoung.blog.csdn.net">原作者博客</a>
            <div id="content_views" class="markdown_views prism-atom-one-light">
                    <svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
                        <path stroke-linecap="round" d="M5,0 0,2.5 5,5z" id="raphael-marker-block" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);"></path>
                    </svg>
                    <p>喜马的容器化历程伴随着公司的发展，并带有很深刻的喜马的烙印：</p> 
<ul><li>以 Java 项目为主；</li><li>Java 项目主要分为 Web 项目和 RPC 项目（基于公司自研的、类似 Dubbo 的框架）；</li><li>发布平台、RPC 微服务框架、网关自研。</li></ul> 
<p>在这个过程中，我们坚持了一些原则：</p> 
<ul><li>开发不用写 Dockerfile，即开发不需要懂容器相关知识；</li><li>测试环境下，开发的电脑可以直接访问容器，即 IP 可以互通。在任何环境，容器集群的物理机上的容器可以和其它物理机 IP 互通；</li><li>K8S 分为 Test、UAT、Product 三个环境，项目配置分为跟环境有关的部分和无关的部分，发布系统及项目信息 DB 部署在测试环境，发布系统可以跨环境访问 Test、UAT、Product 的三个 K8S 集群；</li><li>项目启动失败后，保留现场，不要一直重启。</li></ul> 
<h3><a id="_21"></a><strong>如何让开发发布代码到容器环境</strong></h3> 
<p>2016 年底，我在 Jenkins 机器上安装了 docker，制作一个基于 docker 的项目模板。开发克隆 docker 项目模板，更改源码地址、CPU、内存等配置，由 Jenkins 触发 shell 脚本：</p> 
<ul><li>Maven 编译项目得到 war/jar 包；</li><li>根据 war/jar 拼装 Dockerfile；</li><li>docker build 制作 docker 镜像并 push 到镜像仓库；</li><li>调用 marathon 发布指令。</li></ul> 
<p>当时大概用了 5 天时间搭建了组件，跑通了所有步骤，我们的容器化事业就是从这个最low 的版本开始发展起来的，后来逐步做了以下演进：</p> 
<ol><li> <p>从 marathon 逐步迁移到 Kubernetes。在过渡时期，我们自己实现了一个 docker 发布系统，对外提供发布接口，屏蔽 marathon 和 Kubernetes 的差异；</p> </li><li> <p>实现了一个命令行工具 barge。开发在项目文件中附加一个 barge.yaml 文件，里面设定了项目名等基本配置：</p> </li><li> 
  <ul><li>开发只需 barge deploy 便可以发布项目，barge exec -m $projectName 便可以进入容器内调试代码；</li><li>使用 Google jib 框架基于代码直接制作 docker 镜像，免去了开发电脑上装 docker 的要求，此外也将代码编译、镜像制作过程分散到了每个开发的电脑上，绕过了 Jenkins 单机负载的瓶颈；</li><li>镜像仓库 harbor 的单词 含义的是海港（对应容器的集装箱）。大船是没办法直接开到海港的，到港口后要靠接驳船弄进去，接驳船英文是 barge，所以给项目起名叫 barge， 形容给 harbor 送镜像。至今仍很得意这个命名。</li></ul> </li><li> <p>与公司的发布系统对接（类似阿里云），屏蔽物理机与容器环境的使用差异。</p> </li></ol> 
<h3><a id="_52"></a><strong>一个容器要不要多进程</strong></h3> 
<p>容器世界盛行的理念是：one process per container。但容器在最开始落地时，为了降低推广成本，减少使用差异过大（相比物理机）给开发带来的不适应，需要在容器内运行ssh，实质上要求在容器内运行多进程，这需要一个多进程管理工具（entrypoint不能是业务进程），最终在 runit/systemd/supervisor 中选择了 runit。</p> 
<p>此外，Web 服务每次发布时 IP 会变化，需要让 Nginx 感知到 Web 服务 IP 的变化。我们在每个容器内启动了一个 nile 进程，负责将项目信息注册到 ZooKeeper 上。使用微博一位小伙伴开源的 upsync 插件，并改写了部分源码使其支持了 ZooKeeper（upsync 只支持 etcd 和 Consul），进而使得 Nginx 的 upstream 可以感知到项目实例ip的变化。后来在另一个场景中，Nginx 改用了其它插件，我们将实例信息写入到 Consul 上即可。</p> 
<p>随着 Kubernetes 的铺开，我们使用 gotty + kubectl exec 逐步推广了在浏览器上通过Web console 访问容器。专门的网关系统也投入使用，HTTP 访问由 nginx =&gt; Web服务变成了 nginx =&gt; 网关 =&gt; Web 服务，网关提供了 Web 接口同步 Web 实例数据。ssh 及 nile 进程逐步退出历史舞台。目前，我们的 entrypoint 仍是 runit， 并对其做了微调，当业务进程启动失败时，不会重启（如果 entrypoint 是业务进程时则会频繁重启），以保留现场方便开发排查问题。</p> 
<h3><a id="_68"></a><strong>健康检查的三心二意</strong></h3> 
<p>Kubernetes 有一个 readiness probe，用来检测项目的健康状态，上下游组件可以根据项目的 健康状态采取 相关措施。在 readiness probe 的设置上，经过多次改变：</p> 
<ol><li>每一个 Web 项目会提供一个 /healthcheck 接口，/healthcheck 通过即表示项目启动成功；</li><li>后来发现，对于 RPC 服务，/healthcheck 有时不能表示项目启动成功，需要检测RPC 服务启动时监听的端口是否开启；</li><li>readiness probe配置（HTTP 和 TCP 方式任选）加大了业务开发的配置负担，经常出现配置不准确或中途改变导致 readiness probe 探测失败，进而发出报警，业务开发不胜其烦，我们也非常困扰；</li><li>于是将 readiness probe 配置为 exec 方式，由 nile 根据项目情况自动执行 HTTP 和 TCP 探测，但仍然依赖项目配置信息（比如 RPC 服务端口）的准确性；</li><li>基于“RPC 服务场景下，/healthcheck 接口成功，但 RPC 服务启动失败 的场景非常的少”的判断，我们将 readiness probe 改回了 HTTP /healthcheck 方式。</li></ol> 
<p>liveness 起初是 /healthcheck</p> 
<ol><li>有一次运维改动机房网络，导致 liveness probe 探测失败（kubelet 无法访问本机所在容器 IP）。kubelet 认为 liveness probe 不通过 =&gt; livenessProbe 涉及到 RestartPolicy，大量项目重启 =&gt; 因为项目之间存在依赖关系，依赖服务失败，项目本身启动失败 =&gt; 频繁重启；</li><li>后来我们不再配置 liveness probe ，仅配置 readiness probe：对于物理机损坏等场景，K8S 可以正常恢复；如果容器内存不足 导致实例挂掉，K8S 无法自动重启，这个可以通过内存报警来预防。</li></ol> 
<h3><a id="_93"></a><strong>与发布平台对接</strong></h3> 
<p>喜马拉雅在发布平台的实践中，为了保障线上服务的稳定，沉淀了一套自己的经验和规则。其中一条硬性规定就是：服务端发布任何项目，最开始只能先发布一个实例，观察效果，确认无误后，再发布剩余实例。在实际使用时，验证时间可能会非常长，有时持续一周。这时，Kubernetes deployment 自带的滚动发布机制便有些弱。</p> 
<p>因此，在容器发布系统的设计上，我们让一个项目对应两个 deployment。新代码的发布就是旧 deployment replicas 逐步缩小，新 deployment replicas 逐步扩大的过程。业界有两种方案：</p> 
<ul><li>每次发布新实例，都创建一个 deployment，扩大新 deployment 数量，缩小旧deployment 数量。</li><li>每次发布新实例，都创建一个 deployment 作为灰度 deployment。灰度验证成功，则更新旧的 deployment。我们最开始使用的是第一种方案，缺点就是发布工作分散在两个 deployment 上，所有实例的销毁与创建速度无法控制。此外因为deployment 名字不确定，导致 hpa 配置比较麻烦。</li></ul> 
<p>阿里的 openkruise 实现了一个 crd 名为 cloneset，可以实现上述类似的功能，后续计划逐步替换掉两个 deployment方案 以精简发布系统代码。全新设计一个crd 也是一个很不错的方案。</p> 
<p>此外，容器发布系统对下屏蔽 Kubernetes ，对上提供项目发布、回滚、扩缩容等接口，在接口定义上也多次反复。kubernetes client-java 库也较为臃肿，为此对发布代码也进行了多次优化。</p> 
<p>针对开发日常的各种问题，比如项目 IP 是多少，项目为什么启动失败等，我们专门开发了一个后台，起了一个很唬人的名字：容器云平台。试图将我们日常碰到的客服问题通过技术问题来解决，通过一个平台来归拢，哪怕不能实现开发完全自助式的操作，也可以尽量减少容器开发的排查时间。比如我们开发了一个 wrench 检查组件，用来扫描 Java 项目的 classpath、日志等，分析项目是否有 jar 冲突、类冲突、Tomcat 日志报错、业务日志报错等，开发在 Web 页面 上触发 wrench 执行即可。</p> 
<h3><a id="_122"></a><strong>与已有中间件对接</strong></h3> 
<p>喜马有自己自研的网关及 RPC 框架，最初很少考虑容器的使用场景（比如每次发布 IP 会变化）。此外，服务实例需要先调用网关和 RPC 框架提供的上线接口，才可以对外提供服务。服务销毁时，也必须先调用下线接口，待服务实例将已有流量处理完毕后再销毁。</p> 
<p>为此我们提供了一个 k8s-sync 组件，监听 pod 状态变化，在适当时机调用实例的上下线接口。后续计划自定义 crd 比如 WebService/RpcService，由自定义 controller 完成实例的上下线及其它工作。</p> 
<p>如何做到 Web/RPC 服务的无损上线下线？</p> 
<p><strong>上线</strong></p> 
<p>pod 配置 readiness probe 对项目的 healthcheck 进行健康检查。健康检查通过后，pod 进入ready 状态， k8s-sync 监听到 pod ready事件，调用 Web/RPC 上线接口。readiness 由 K8S 确保执行，可保证健康检查不成功不会上线。风险是如果 k8s-sync 挂了则健康检查通过的 pod 无法上线。解决办法：</p> 
<ul><li>k8s-sync 容器部署，或者 systemctl 管理，挂了之后可以立即重启；</li><li>k8s-sync 通过 Prometheus 抓取数据，配置了报警，挂了之后可以迅速通知到容器开发。</li></ul> 
<p><strong>下线</strong></p> 
<p>K8S 先执行 pod preStop 逻辑，preStop 先调用 Web/RPC 下线接口，执行 xdcs 提供的零流量检查接口，检查通过，则 preStop 执行完毕，销毁。若项目未接入 xdcs，则等待 preStop 等待 10s 后，执行完毕。销毁 =&gt; preStop 由 K8S 负责确保执行， 正常发布/删除/节点移除/节点驱逐 都可以确保被执行，以确保服务无损。如果物理机节点直接挂了，则无法保证无损，因为一系列机制都来不及执行。</p> 
<p>k8s-sync 同时也将 pod 信息同步到 MySQL 中，方便开发根据项目名、IP 等在后台查询并访问项目容器。随着 k8s-sync 功能的丰富，我们对 k8s-sync 也进行了多次重构。</p> 
<h3><a id="_163"></a><strong>体会</strong></h3> 
<p>从 2016 年到现在，一路走来，容器的各种上下游组件、公司的中间件并不是一开始就有或成熟的，落地过程真的可以用“逢山开路遇水搭桥” 来形容。</p> 
<p>1、我们花了很大的精力在容器与公司已有环境的融合上，比学习容器技术本身花的精力都多。为此我经常跟小伙伴讲，我们的工作是容器化，其实质上容器技术“喜马拉雅化”。</p> 
<ul><li>技术上与各种中间件做整合。为此开发了 k8s-sync，改造了 upsync；</li><li>不要求开发 docker，写 dockerfile。为此开发 barge，容器云平台等。</li></ul> 
<p>2、实践的过程仿佛在走夜路，很多方案心里都吃不准。为此看了很多文章，加了很多微信，很感谢一些大牛无私地交流。对于一些方案，走了弯路，兜兜转转又回到了原点。但这个过程逼得我们去想本质，去反思哪些因素是真正重要的，哪些因素其实没那么重要，哪些问题必须严防死守，哪些问题事后处理即可。</p> 
<p>3、成长经常不是以你计划的方式得到的。</p> 
<p>比如最开始搞 Kubernetes 落地的时候，想着成为一个 Kubernetes 高手，但最后发现大量的时间在写发布系统、k8s-sync，但再回过头，发现增进了对 K8S 的理解。</p> 
<p>笔者 Java 开发出身，容器相关的组件都是 GO 语言实现的，在最开始给了笔者很大的学习负担。但两相交融，有幸对很多事情理解得更深刻，比如亲身接触 Java 的共享内存模型与 GO 的 CSP 模型，最终促进了对并发模型的理解。</p> 
<p>为了大家多用容器，我们做了很多本不归属于容器开发的工作。尤其是在容器化初期，很多开发项目启动一有问题便认为是 docker 的问题， 我们经常要帮小伙伴排查到问题原因，以证明不是 docker 的问题。这是一个很烦人的事情，但又逼着我们把事情做得更好，更有利于追求卓越。比如 wrench 的开发，真的用技术解决了一个看似不是技术的问题。</p> 
<p>4、一定要共同成长，多沟通，容器技术改变了基础设施、开发模式、习惯，尽量推动跟上级、同事同步，单靠一个人寸步难行。</p> 
<p>最后想想，感慨很多，还是那句：凡是过往，皆为序章。</p>
                </div>
            </body>
            </html>
            